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Abstract 

This paper presents the hyperwall , a visualization clus- 
ter that uses coordinated visualizations for interactive ex- 
ploration of multidimensional data and simulations . The 
system strongly leverages the human eye-brain system with 
a generous 7x7 array of flat panel LCD screens powered by 
a beowulf cluster. With each screen backed by a worksta- 
tion class PC , graphic and compute intensive applications 
can be applied to a broad range of data. Navigational tools 
are presented that allow for investigation of high dimen- 
sional spaces. 

Keywords — Scientific visualization, multivariate analysis, 
linked views, brushing 

1 Introduction 

That data are growing in size and complexity is self 
evident, no more so than when it comes to multidimen- 
sional/multivariate (MDMV) data. Scientific and Informa- 
tion visualization literatures are filled with research delv- 
ing into the issues associated with this data explosion. A 
common theme emerges: sooner or later, machines run 
out of some precious resource, be it CPU, graphics, screen 
real estate, memory, or disk bandwidth. Screen space, for 
instance, has been a limiting factor in MDMV visualiza- 
tion systems ever since the first brushed scatterplot matrix 
[1, 2]. One can only display so many windows, can only 
present so many variables in a single view before reaching 
a point of diminishing returns. 

We seek to interactively explore large, MDMV datasets 
and families of parameterized simulations. Towards this 
end we have assembled a system using a combination of 
commodity hardware and custom software known as the 
’hyperwall’. Combining a phalanx of pixels and proces- 
sors, we seek to overcome some of the graphics and com- 
putational limitations found in many MDMV visualization 
systems and work towards a true problem solving environ- 


ment where many tools can be brought to bear on a given 
problem at once. 

There are many approaches to MDMV visualization, 
the goal typically being to visually summarize and interact 
with the data searching for trends and relationships. Tools 
such as XGobi [3] and XmdvTool [5], use techniques such 
as scatterplots, glyphs, and parallel coordinates to display 
MDMV data in lower dimensional projections. Direct ma- 
nipulation techniques such as interactive brushing are used 
to find relationships between variables. These packages 
draw on the works of authors such as Tukey and Cleve- 
land, providing a rich set of the classic statistician’s tools 
to bring to bear on the data. Other research has focused 
on multiple, coordinated views or visualizations of related 
data. North and Shneiderman have revealed the efficacy 
of these techniques across a broad spectrum of problems. 
Finally, a number of tools have taken a spreadsheet ap- 
proach to MDMV visualization, where the layout of the 
views have inherent meaning, implying location and allow- 
ing navigation in a given high dimensional space. This ap- 
proach also allows a high degree of coordination between 
views, for instance when a given modification or operation 
is applied to all visuals in a column or some other subset 
of the matrix. 

The hyperwall exists at the confluence of these streams, 
combining spreadsheet metaphores, direct manipulation, 
and multiple linked coordinated views. 

2 System Architecture 

The core of our system is a 49-node beowulf cluster. 
Each node uses an nVidia GeForce4 graphics card to drive 
one of the LCD flat screen monitors arranged in a 7x7 ma- 
trix on a custom rack. This gives us around 64 million 
pixels spread across some 55 square feet of screen real es- 
tate. All nodes run without a keyboard or mouse, and cus- 
tom software has been written to allow a user to interact 
with the nodes. This software, hyperx, captures all mouse 
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and keyboard events on a master node and broadcasts the 
identical X event stream to any or all nodes allowing user 
control of any GUI-based software running on the cluster. 

3 Spreadsheet-Based Visualization 

Since we lay our visualizations out in a matrix, our sys- 
tem is related to spreadsheet-based visualization systems 
[6, 7, 8] and gains many of the inherent benefits thereof. 
The position of a visualization in our matrix of screens 
can be directly related to a location in a high dimensional 
space, providing the user with a necessary context for un- 
derstanding and navigating MDMV spaces. For instance. 
Fig 2 shows a parameter study of the Reusable Launch Ve- 
hicle. Each row displays a different angle of attack, each 
columm a different Mach number. The user knows, at a 
glance, the parameters associated with the dataset in each 
view. 

Like other spreadsheet-based systems, the simultaneous 
display of related visualizations facilitates a broad range of 
primarily visual activities such as comparing and contrast- 
ing related images, tracking features between timesteps, 
and finding patterns amidst the complexity of a family of 
bivariate scatterplots. Furthermore, with aggregate visual- 
izations (using possibly several different applications), we 
can explore visualization space as well as data space, look- 
ing at our data in a number of ways at once. Our system 
provides well for these visual tasks by providing high res- 
olution views of all visualizations and allowing for a high 
degree of interactivity with these views by the user. 

3,1 Caveats 

One way in which we differ from spreadsheet-based vi- 
sualization systems is that, in general, we do not have a 
built in programming language. This would allow one, 
for instance, to calculate the difference between the scalar 
fields on two nodes, and display the results on another. 
However, this might require a high degree on integration 
between software on the master node and software running 
on the nodes. While we have written applications that are 
as tightly coupled as this, node application software can 
often be run unmodified. This loose coupling greatly ex- 
tends the number of applications we can use on the cluster 
especially those for which we do not have source. Alas, 
some features may require code modification no matter 
what. For example, synchronized animation across mul- 
tiple nodes will typically involve some external synchro- 
nization mechanism probably not anticipated in a given ap- 
plication. 

4 Coordinated Visualizations 

In our system, nodes either work together in order to 
display one scene (like a powerwall), or they each indi- 
vidually display a separate (possibly related) scene. Co- 
ordination in the powerwall sense requires that all nodes 


render the same scene at the same time with a shared set 
of viewing transformations. At the other end of the spec- 
trum, each node displays possibly a different dataset, or the 
same dataset using a different rendering parameter, or even 
a compledy different visualization technique. Coordina- 
tion in this case may mean that all the nodes have the same 
viewing transformations, or that the same colormap is used 
across the different datasets. In any case, we achieve co- 
ordination of views by providing each node with the exact 
same stream of X events. 

4.1 Using X to interact with the nodes 

Using the X Test extension distributed with X11R6, 
we can send simulated mouse and keyboard events to X 
servers running on any of the nodes. Using custom soft- 
ware, called hyperx, a user can sit at the master node and 
interact simultaneously with any number of nodes in the 
matrix. This allows one to change such things as view 
perspective, color mapping, visualization type, or any pa- 
rameter of a visualization accessible via a GUI. Imagine 
interactively changing a cutting plane position through 49 
different datasets at once, and you begin to see the possibil- 
ties of such as system. Another nice feature is the ability to 
move the mouse and keyboard around screen to screen as 
if you are interacting with one very large virtual desktop. 

4.2 Issue: Maintaining View Coherence 

In powerwall mode, when a group of nodes are coop- 
erating to show a single scene, all the nodes must agree 
upon the current set of transformations. Similarly, when 
groups of nodes independantly render related objects, we 
typically want to have the same viewpoint across all of 
them. Transformations or viewpoints are usually modified 
via the mouse or keyboard. Thus, we can often achieve 
view coherence by sending the exact same event stream to 
each node though there are again some subtleties that may 
require modifications to software running on the nodes. 

When adjusting the view with the mouse, an X-based 
application will typically pass through the main loop many 
times as the mouse is dragged. Since we want all ganged 
nodes to respond identically, any source of asynchronic- 
ity in the event production or consumption must be hunted 
down and removed. Thus for example, all event compres- 
sion must be turned off. Other sources of asynchronicity 
are X workprocs, and callbacks from I/O events on sock- 
ets registed via XtAppAddlnput. Self generated X events 
can be another source of disparity in the event stream and 
hence lead to divergance of transformations and viewoints. 

Once these and other sources of randomness in either 
the event stream production or consumption have been re- 
moved, the remaining issue is that of graphics throughput. 
Suppose, as you are drawing your scene across four nodes 
ganged in a 2x2 array, one node’s portion of the view frus- 
tum happens to contain a bulk of the polygons in the isosur- 
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Figure 1 : Architecture. 
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Figure 2: Examining an RLV parameter study. 
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face being rendered. Its frame rate drops to say, 3 fps while 
the other nodes gallop merrily along at 15 fps. The views 
will in this case diverge until the user releases the mouse, 
whereupon the views will again converge when all nodes 
in the gang have digested all the events in their identical 
event streams. If needed, a finer grained approach using 
some sort of distributed synchronization mechanism such 
as a barrier can remove this remaining issue, and provide 
frame for frame view coherence. This is needed for things 
such as synchronized animation. 

43 Powerwall mode 

Sooner or later, everyone eventually asks if we can show 
one image over all the screens (like a powerwall). The an- 
swer is yes, with some reservations. Unless you are using 
Chromium [10] to divide up of the graphics work, in gen- 
eral, node application software will need to be modified. 
We have used Chromium on our cluster but at the time, 
there were performance issues related to using only fast 
ethemet between nodes, as well as issues with display lists 
and applications using multiple windows. 

For 2D scenes, such as rendering an image, there is an 
implied XY offset into the image based upon its location in 
the wall. Image rendering software would need to calculate 
the relevant subrectangle for its portion of the view, possi- 
bly affecting I/O, buffering, and display routines. Display- 
ing 3D scenes across an array of screens can be achieved 
by dividing up the view frustum appropriately and having 
each node render the entire scene. While this seems waste- 
ful, the efforts required for culling the scene via octrees, 
or other suitable schemes, usually does not become nec- 
essary until the rendered scenes become completely un- 
wieldy. Modem graphic cards like the GeForce4 and its 
contemporaries are quite capable of rendering millions of 
polygons per second. Of course, one could come up with a 
giga-polygon isosurface to foil us here but in practice, this 
has not been an issue. View coherence is an issue however 
as discussed in section 4.2. 

5 Navigating in Hyperspace 

The complexity of MDMV datasets inspires us and cries 
out for novel tools to search around for new unseen rela- 
tionships. Inevitably, there is the tension between com- 
plexity of task and simplicity of interface. 

For example, navigation is one of the primary chal- 
lenges in MDMV visualization. Successful interfaces for 
navigation are often intuitive, provide contextual informa- 
tion, and are flexible enough to get the user where they 
want to go. A good example of MDMV navigation is the 
HyperSlice [4] interface. The user is presented with an 
array of bivariate plots, each of which is centered on an n- 
dimensional point C = (Xi,X 2 , ...,X n ) This point can 
be moved around in n-space by direct manipulation. By 


grabbing in the Xi , X 2 subplot the user changes those co- 
ordinates of C, leaving all the other dimensions X 3 ...X n 
constant. This interface gives immediate feedback to the 
user via direct manipulation, provides contextual informa- 
tion for the user through the meaningful layout of the sub- 
plots, and allows the user to navigate the center point C, 
anywhere in the n-dimensional space. 

For our purposes, we have several datasets requiring 
navigation through a 6D space. One example, is the vi- 
sualization of the electron pair density function. Given 
a molecule, we consider an nearby electron. Then, for 
each possible position of that electron in 3-space around 
the molecule, we consider all possible positions of a com- 
panion electron. With 3 degrees of freedom for each elec- 
tron, this results in the 6D electron-pair density function 
which we wish to explore in order to find electron-rich or 
electron-poor areas. 

For our purposes, it made sense to move a hyper- 
plane around instead of a hyperpoint like the HyperSlice 
interface. On a given node, 3 dimensions of the data, 
say (X,Y, Z), can be represented with volume render- 
ing or some other suitable 3D scalar visualization tech- 
nique. Then, with a navigational tool running on the mas- 
ter, we can interactively assign the remaining 3 dimensions 
(U, V, W) by orienting a plane in 3D. On the plane are ar- 
ranged an array of points, each of which represents a node 
in the cluster (and hence, a screen on the wall) and has a 
unique (U, V, W) coordinate. 

If the nodes are running a simulation, then the coordi- 
nates are typically continuous and are sent to the nodes to 
update their displays. Thus for example, each node would 
do a volume rendering of all (X, Y, Z) data for a fixed 
(U, V, W). For the situation when the (U, V, W) coor- 
dinates are discrete the coordinates for a given node would 
be ’snapped’ to the nearest valid coordinate. An example 
might be data files associated with a parameter study where 
a coordinate change might require the nodes to load a dif- 
ferent file. 

6 Interactive Parameterized Simulations 

With the advent of workstation class PCs, significant 
computational power is availible to throw at a problem. 
When combined with an array of graphics displays, we 
approach an environment where we can exercise compu- 
tational steering[9]. 

Our system allows us to run parameterized families of 
simulations in parallel. However, computational steering 
environments often require that one ’instrument’ the simu- 
lation code in order to give the user feedback (monitoring) 
and allow interactive control (steering). For monitoring, 
the simulation code is often modified to allow display of 
the state of the simulation. Another modification would be 
to allow user access to the simulation’s runtime parameters 
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Figure 3: Six-D browser interface here shown with a schematic water molecule. This interface allows the user to coordinate 
the simulations seen in Figure 4. 



Figure 4: The Six-D browser allows interactive exploration of the electron pair density function around a water molecule. 
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for steering. Both of these modifications are delicate and 
obviously require in-depth analysis of any simulation code. 

As an example, a molecular simulation code known 
as COSMOS (Computer Simulations of MOlecular Sys- 
tems) has been instrumented by NASA researchers Chris 
Henze and Brian Green. Every time COSMOS completes 
a timestep, it sends the updated atom positions to a viewer. 
Within the viewer, the user can interact with the simula- 
tion by selecting individual molecules and moving them 
around. Furthermore, using an interface on the master 
node, forces such as compression, expansion, rotation, and 
shear can be applied. 

Within the hyperwall environment, dozens of these sim- 
ulations can be run in parallel. Fig 5 displays thumbnail 
snapshots from a set of carbon nanotube simulations each 
of which has been subjected to an expansive force inter- 
actively supplied by the user. Again, layout in the ma- 
trix implies position in this parameter space of nanotubes. 
Along the diagonal, from top to bottom, the nanotubes 
grow larger. Greater distance above and below the diag- 
onal corresponds to more twist (also known as the chirality 
number) in a clockwise or counterclockwise direction. We 
can see that, in general, the smaller tubes tend to break 
apart with the level of force applied by the user. 

7 Conclusion 

We have presented the hyperwall, a system capable of 
interactive exploration of MDMV data and simulations. 
Because we have a full blown beowulf cluster, each node 
of which is armed with its own graphics card, we can run 
compute and graphics intensive applications, bringing a 
powerful array of tools to bear on any given problem. This 
allows us to compute whole arrays of visualzations or sim- 
ulations in parallel, displayed at high resolution, in a highly 
interactive fashion. The sheer visual nature of the display 
system encourages people to scan the displays looking for 
trends, relationships, and anomilies. We find that scientists 
want to walk right up to the wall of screens, look closer, 
and point out observational curiosities to co-investigators 
making it inherently collaborative in nature. 
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Figure 5: Realtime interaction with a family of nanotube simulations. 
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